I've finally written some comprehensible documentation for my open-source eFuse OTP memory compiler, which was used to generate eFuse IPs for the Run 1 testchip. In case someone is considering using eFuse in their design during later runs, please check it out. I'm open to any suggestions regarding compiler improvements, and would be happy to assist with eFuse IP integration if needed.
If it is helpful, I have a pretty nice systemverilog testbench I can share when I used to teach a SerDes course. It is integrated into virtuoso, Basically, it drops a random 8 bits out -> 8b10b encoding -> PISO -> channel driver -> channel -> CTLE/AMP/DFE -> slicer -> 10b8b decode -> compares to the random 8bits that should have been sent and flags it. There is a CDR attached to the slicer. it is not PAM4 but it could be extended to that.
Well, it is system verilog, I could share the testbench structure. Basically, I had students design everything from the 8b10b output to the 10b8b input via schematics in FreePDK15 and FreePDK3. I could help stand up the FreePDKs at least from questions and simulations if needed. I upgraded the FreePDK15 to have integration in cadence instead of python wrappers and I did the TCAD to Spice on the models and setup a cadence PDK for schematics (no DRC/LVS).
5:09 a.m.
I can share my systemverilog source
5:09 a.m.
and I can check to make sure that the 8b10b and 10b8b encoding/decoding is shareable (I think I snagged it offline).
5:10 a.m.
The real power in it is that all bits that go down the channel are kept in a memory in the testbench and then they are checked as they come off the final reciever. I also have some VerilogA and VerilogAMS of all the other components in there as well.
5:12 a.m.
If you can do mixed mode simulation then this is a good testbench for SerDes. I have one with a verilogA PLL and another with a verilogAMS DLL. have a few topologies things as well in there.
5:15 a.m.
I am not sure I will have the time to port it over the next couple of months. I also have something similar for a flipflop.
I have a pile of stuff from the Digital Electronics course I taught for a while. At some point I guess I need to just port it to opensource and put it in the wild. but there are only so many hours in the day and I am spoiled with industry tools.
5:28 a.m.
Oh, I didn't hit reply to you @Tim 'mithro' Ansell
beardothaweirdo
I have a pile of stuff from the Digital Electronics course I taught for a while. At some point I guess I need to just port it to opensource and put it in the wild. but there are only so many hours in the day and I am spoiled with industry tools.
It was a PhD level class... as far as I know I am the only undergraduate I know that had ever taken in when Dr. Franzon was teaching the course. It was how I got into his research group as an undergraduate.
beardothaweirdo
If you can do mixed mode simulation then this is a good testbench for SerDes. I have one with a verilogA PLL and another with a verilogAMS DLL. have a few topologies things as well in there.
Verilog-A → OpenVAF → ngspice
Digital → Verilator
Is one possible, no vams though just verilogA which is workable (you can just break verilogams into a verilogA and verilog file, but that is not as closely coupled @Matt G. (Mobius)(edited)
4:50 p.m.
Gnucap Verilog-AMS is an attempt that is out there. Maybe we can improve it to support. Not opposed to writing a proposal for it either.
Matt G. (Mobius)
I'm not sure I like this discord threading. (I don't usually use discord)
Verilog-A → OpenVAF → ngspice
Digital → Verilator
Is one possible, no vams though just verilogA which is workable (you can just break verilogams into a verilogA and verilog file, but that is not as closely coupled @Matt G. (Mobius)(edited)
One thing with respect to the verilog-a -> OpenVAF flow is that the Verilog-a syntax support is very minimal. I believe this was intended to support device models that are in Verilog-a first and foremost, and less so about supporting behavior models e.g. for vcos or other analog blocks. So a lot of the models you might find on designer's guide won't work with this flow to my knowledge.
Thomas Dexter
One thing with respect to the verilog-a -> OpenVAF flow is that the Verilog-a syntax support is very minimal. I believe this was intended to support device models that are in Verilog-a first and foremost, and less so about supporting behavior models e.g. for vcos or other analog blocks. So a lot of the models you might find on designer's guide won't work with this flow to my knowledge.
3
1